One of the most common sales mantras is “know your customer.” This basic tenet of selling has grown far beyond knowing who enters the store; it requires among other things, knowing what attracts customers, what they look at, how they move around a marketplace, and how long they stay. By studying customer buying habits, retailers have been able to maximize their revenues through tailoring their promotions, offerings, and even store layouts to suit their customers' preferences and habits.
For bricks-and-mortar sellers of goods and services, gathering such data rapidly becomes cost-prohibitive. Identifying basic information about customer behavior at the check-out stand may be fairly cost-effective; but monitoring a customer's path through the store or how long customers spend selecting a particular product requires much more expensive monitoring. In contrast, such behavioral tracking in the on-line environment occurs without significant increases in cost, thus making complex data collection not only possible, but a requirement to remain competitive.
In an on-line environment, website usage and other customer behavior may be tracked by a website server, or by another server such as a data collection server (also known as a data collector), which may be remotely located. The data collection server is notified of activity on a website so that it can monitor and track the activity. One method of achieving this notification is through the use of a request for embedded content.
Embedded content is part of a web page, such as an image, that is requested as a separate file from the file containing the web page. The separate file may be requested from the website server or from a remote server, such as a remote content server or data collection server. For example, when a user requests a web page from a website server, the website server sends the web page file to the user's client. The client, such as a web browser, then attempts to render the file as a viewable web page. However, upon rendering the web page file, the client may find a reference to a separate file located on the website server or a remote server. After the content is located and sent to the client, the client renders the separate file containing the embedded content along with the original web page.
A web beacon (also known as a web bug) is a particular type of embedded content where the content itself is irrelevant, but the request for content carries useful information. For example, a web beacon is often a transparent image having very small dimensions, such as 1 pixel by 1 pixel. This image is small enough to be invisible to the user both visually and with respect to its effect on perceived response time. When a client is rendering a web page that includes a web beacon, the web beacon causes the client to send a resource request to a server such as a data collection server. The web beacon may include a script (or other code) that causes the client to include, in the resource request, additional information about the user and the user's environment. The additional information can include the data from a cookie, or other information about the client's operating environment or status. Where the server indicated by the web beacon code is a data collection server, the data collection server may, in response to the request, cause the client to set an additional cookie for identification for tracking purposes. In this manner, the web beacon request can be used to indicate to a data collection server that a particular web page is being rendered.
One method for including the request is to write the request as a static image tag in Hypertext Markup Language (HTML). The following is an example of an image tag in HTML:<imgsrc=“http://ad.datacollectionserver.com/tracker.exe?AID=14658&PID=259294&banner=0.gif” width=1 height=1 border=0>
Here, the term “ad.datacollectionserver.com” refers to the address of the data collection server.
Another common method of including the request is to use a scripting language such as JavaScript so as to cause the browser to dynamically generate a request to the data collection server. One advantage of using a script instead of a static image tag is that the script can cause the browser to perform other functions including gathering additional data and sending it along with the request. In either case, the result is a request sent to the data collection server upon the occurrence of an event, such as the loading and rendering of a web page.
Once the request has been sent to the data collection server, the data collection server can perform various types of tracking functions. For example, the data collection server can count the number of requests associated with a web page so as to monitor traffic on the web page. By counting the number of times the web beacon element has been requested from the data collection server, the server can determine the number of times a particular page was viewed. By using JavaScript to dynamically construct the request for the web beacon and encode additional information, other identifying information can be obtained for further analysis.
Other types of website usage tracking are also well known, such as for example log file analysis. In such an approach, statistical analysis is performed on server logs in order to detect and analyze website traffic and usage patterns.
In addition to tracking web page visits, it is often desirable to track user actions, such as element activations, on web pages. In general, existing approaches for collecting and tracking website usage fail to provide a means for tracking the actual links a user clicks on during the course of navigating a site and/or fail to provide a connection between the links and return on investment. In some circumstances, the link clicked on can be inferred if the start page has only one link that leads to the destination page. However, where there is more than one link between pages, the determination of which link was clicked, and thus which link contributed to a sale, is more difficult or impossible. Additionally, even when there is only one link, it is often difficult or impossible to determine whether the user actually clicked on the link or navigated to the page via some other method (such as typing in the URL).
Such information is useful in many ways, including for example collecting feedback that leads to improved web page design, determining the effect of various degrees of prominence of links and graphic elements on web pages, and determining the contribution of individual links to an eventual sale. What is needed, then, is a method and system for reliably and accurately tracking the actual links a user clicks on (and other elements the user activates) during the course of navigating a site. What is further needed is a mechanism for automatically and uniquely identifying links on a page so that the user's interactions with the links can be accurately tracked. What is further needed is a mechanism for associating the sales from a website with the links. What is further needed is a mechanism for accurately reporting web page element usage and value statistics. What is further needed is an improved report format that visually depicts web page element usage and valuation statistics.